home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 11
/
Cream of the Crop 11-1.iso
/
comm
/
onefos08.zip
/
ONEFOS.TXT
< prev
next >
Wrap
Text File
|
1996-01-11
|
42KB
|
787 lines
ONEFOSsil FOSSIL 5 Communications Driver Revision 8
(c) Copyright 1995-96 by Carl Morris and Morris Softronics,
all rights reserved
Published and released by Morris Softronics on January 12, 1996
Table of Contents
Topic Location
------------------------------------------------------------------------
What is ONEFOSsil? . . . . . . . . . . . . . . . . . . . . . . . . . 1
Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Licensing Information . . . . . . . . . . . . . . . . . . . . . . . . 3
Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
Registration . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Benefits of Registering . . . . . . . . . . . . . . . . . . . 3-3
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Port Argument . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Command Line Options . . . . . . . . . . . . . . . . . . . . . 5-2
Locking Port Settings . . . . . . . . . . . . . . . . 5-2-1
Setting Buffer Sizes . . . . . . . . . . . . . . . . . 5-2-2
Setting Multitasker Options . . . . . . . . . . . . . 5-2-3
Controlling FIFO's . . . . . . . . . . . . . . . . . . 5-2-4
Holding the Interrupt . . . . . . . . . . . . . . . . 5-2-5
Controlling Time-outs . . . . . . . . . . . . . . . . 5-2-6
Controlling Carrier-Detection . . . . . . . . . . . . 5-2-7
After Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Un-installing . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Getting Status . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Changing Port Settings . . . . . . . . . . . . . . . . . . . 6-3
Forcing Port Opened . . . . . . . . . . . . . . . . . . . . . 6-4
Forcing Port Closed . . . . . . . . . . . . . . . . . . . . . 6-5
Examples of Installation and Use . . . . . . . . . . . . . . . . . . . 7
Compatibility Notes . . . . . . . . . . . . . . . . . . . . . . . . . 8
Shared IRQ's . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
Pretested Software . . . . . . . . . . . . . . . . . . . . . 8-2
Windows Tips . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Troubleshooting (obtaining support) . . . . . . . . . . . . . . . . . 9
Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Section 1: What is ONEFOSsil?
ONEFOSsil is a high speed serial communications driver for 8250 series
UARTs. The 8250 series includes all compatible UARTs, including the
8250A, 8250B, 16450, 16550, 16550A, and the 82510 in 16450 compatibility
mode. Other UARTs are sure to exist that may be compatible.
ONEFOSsil provides services for FOSSIL compliant software. ONEFOSsil
supports most of the FOSSIL 5 specification and the Extended X00 FOSSIL
specification. ONEFOSsil will probably work with any program that is
designed to use a FOSSIL driver. Some differences do exist between
ONEFOSsil and a full FOSSIL 5 driver, and the technical document,
ONEREF.TXT, describes these differences. Very few of these differences
should cause problems.
ONEFOSsil is special (it can't be called unique) in that it only
supports one FOSSIL port at a time. This provides the best solution for
multitasking environments such as DESQview or Windows where only one
port is needed in each task. Just because ONEFOSsil is a single port
driver, that does not stop it from being useful for multiport or
multiline systems. ONEFOSsil can even handle multiple ports that share
the same IRQ (read Compatibility Notes - Shared IRQ's.)
Some people ask why there is a need for another FOSSIL driver. Other
people are finally relieved to see new FOSSIL drivers. Its been nearly
two years since the last update of any FOSSIL driver. Most drivers are
much older than that yet. Many of the current drivers are loaded with
bugs, and the versions that are bug free are lacking needed features.
Most drivers are not even supported by their authors anymore.
ONEFOSsil was wrote to fill this gap completely. ONEFOSsil not only
provides an alternative, but a better solution. The author stands
behind ONEFOSsil, promotes it and FOSSIL compliant software, and is
willing to take the heat. In a time where more and more software is
becoming less and less DOS based, it is hard for anyone to provide and
support such a product as ONEFOSsil. It is only for this reason that
ONEFOSsil has been produced as a shareware product. By supporting the
author, you show the author your support of his work in supporting the
product.
Section 2: Warranty
The shareware version of ONEFOSsil comes with absolutely no warranty.
Due to the instability of modern media and the unreliability of
communications devices, it can not be guaranteed that this copy of
ONEFOSsil is in the same state as when it was released. Use of this
software and/or documentation is at your own risk.
Carl Morris, Morris Softronics, or any of their distributors can not be
held responsible for any accidental or consequential damages this
product may cause, including destruction of data, or damage to
equipment. No warranties exist on the use of this product, either
expressed or implied, and is hereby disclaimed of any and all implied
warranties of merchantability and fitness for a particular purpose.
The only expressed warranty of the registered version of ONEFOSsil is if
ONEFOSsil ever performs incorrectly, ONEFOSsil will be corrected and a
new registered version will be made available. This is based on Morris
Softronics judgment of "performing incorrectly."
Section 3: Licensing Information
Since ONEFOSsil is primarily a shareware product, several licenses apply
to its distribution and use. ONEFOSsil is protected by U.S. copyright
laws and international copyright treaties and is licensed, not sold.
Section 3-1: Distribution
Distribution rights of this copy of ONEFOSsil is described in the file
DISTRIB.TXT supplied with this copy.
Section 3-2: Registration
The shareware version of ONEFOSsil is for evaluation only. After the
evaluation period, the full version of ONEFOSsil must be licensed for
use, or the shareware version must be removed from use. The file
REGISTER.TXT supplied with ONEFOSsil will detail the registration
process.
Section 3-3: Benefits of Registering
Registration of a shareware product is usually done to extend the
usefulness or enjoyment of a product. Shareware products usually come
crippled, or with some form of a reminder, or both. ONEFOSsil is not
crippled in any way. ONEFOSsil will display a registration reminder and
beep every time it is ran. ONEFOSsil will delay 5 seconds when it is
installed. This is a small price to pay to evaluate cripple free high
performance software such as ONEFOSsil.
Registration of ONEFOSsil will include, but not be limited to: an
indefinite license agreement, an executable without the delay and
reminder, free (from registration costs) upgrades to newer versions,
enhanced support from the author, and discounts and specials on other
products from Morris Softronics.
Section 4: System Requirements
To be effective and useful, ONEFOSsil requires the following: MS DOS 3.0
or compatible operating system, a minimum of 64k of memory(uses 4k
minimum for installation), an 80286 or compatible processor, an 8250 or
compatible UART, and software that is FOSSIL 5 compliant.
Almost any application that is FOSSIL 5(or less) compliant should
function with ONEFOSsil. Lots of new applications that use FOSSIL
drivers are appearing all the time, so it is hard to say that any
specific kind of software will or will not use ONEFOSsil.
Section 5: Installation
NOTICE: As of revision 8, some functions have not yet been completed.
Notes will appear if a function is still being written. Please read
Troubleshooting if any problems arise.
ONEFOSsil knows little, and assumes less about the computer it is being
used on. ONEFOSsil gets all its information about the computer off the
command line. ONEFOSsil's command line is simple to use when
installing. Only one argument is required; all other arguments are
optional, and may be placed in any order after the first argument. The
following is the syntactical use of ONEFOSsil for installation:
ONEFOS port=address,irq [L=[baud][[,format][,flow]]]
[B=[write][[,read][[,stop][[,continue]]]]]
[S=os[,sensitivity]] [F=[buffer][,trigger]] [H] [T=time]
[D[=delay]]
Details on each option are in the following sections. Refer to Examples
of Installation and Use if additional help is required. Notice that
ONEFOSsil's command line is case insensitive. The letters A and a are
treated the same.
An error level of 0 is returned if ONEFOSsil was successfully installed.
Section 5-1: Port Argument
The port=address,irq argument is the only argument required to install
ONEFOSsil. However, seldom will ONEFOSsil work at it its best potential
knowing that little and assuming the rest.
The port value is the decimal number of the communications port
ONEFOSsil is to provide services for. It may be any value from 1 to 64.
Not all software support ports greater than 8 or 16. In most cases,
port 1 is the same as COM1 and so on, but may be changed at will for
special circumstances.
The address and irq values provide ONEFOSsil with the hardware address
for the UART it is to provide services for.
The address value is a hexadecimal number that details the base
input/output address for the UART. Valid values for address range 100
though FFFF.
The irq value is a decimal number that details the hardware interrupt
request line the UART will use to signal ONEFOSsil to communicate with
the UART. Valid values for irq are 3 though 5, 7, 9 through 12, and 15.
If a value of 2 is needed, the value 9 will work.
The following table displays some common values used for port, address,
and irq.
COM Port port address irq
-------------------------------------
COM1 1 03F8 4
COM2 2 02F8 3
COM3 3 03E8 4
COM4 4 02E8 3
Notice that ONEFOSsil refers to ports the same way most software do;
other FOSSIL drivers do not. This was done to make ONEFOSsil simpler to
use specially in batch files that need to use ONEFOSsil commands after
ONEFOSsil has been installed, but more on that later.
Section 5-2: Command Line Options
Following the port=address,irq argument may follow any number of options
in any order, provided no option is repeated. Most of these options
change ONEFOSsil's usefulness or performance. For some computers and
software, some of these options seem mandatory. The following sections
describe each option in detail. It is encouraged that people should
read each section carefully to see which options may apply to their
computer or software.
Section 5-2-1: Locking Port Settings
The most often used option in FOSSIL installations is the settings
locking options. With ONEFOSsil, almost anything that can be configured
by applications can be locked on the command line, to prevent an
application from changing it. This is primarily what the settings
locking options are for. With high speed modems, the "computer to
modem" speed seldom changes, and so is locked to prevent applications
from changing it. Most configurations also only use an "8N1" data
format, and so often lock it, to prevent possibly buggy software from
changing it. ONEFOSsil has an added option; ONEFOSsil can lock which
types of flow control are to be used, preventing applications from
changing them. The syntax for ONEFOSsil's settings locking option
follows:
L=[baud][,[format][,[flow]]
What this shows is that all values are optional. If a value is not
specified, a comma should still be placed between the missing values.
Trailing commas are not permitted, and of course, if no values are
specified, one should not place L= on the command line.
The baud value defines the baud rate that will always be used to
communicate on this port. Applications are not permitted to change it.
Only ONEFOSsil may later change or clear this value. Often, high speed
modems have an option to remain at one speed all the time. If the modem
on the port works this way, the baud value should be used to specify
this speed. For slow speed modems, this value should usually not be
used. The baud value may be 110, 150, 300, 600, 1200, 2400, 4800, 9600,
19200, 28800, 38400, 57600, or 115200.
The format value defines the data format that should always be used to
transmit and receive characters. Applications are not permitted to
change it. Only ONEFOSsil may later change or clear this value. Most
configurations only call for 8 data bits, no parity, 1 stop bit. Unless
need warrants, this value should always be locked to "8N1". The format
value is specified by combining one value from each of the following
groups: data bits - 5, 6, 7, or 8; parity - N for none, O for odd, E for
even, M for mark, and S for space; stop bits - 1 or 2.
The flow value defines which methods of flow control should be locked.
Applications will not be permitted to set or remove flow control options
locked here. Only ONEFOSsil may later change any flow control options
which have been locked. Flow control can both be locked enabled or
locked disabled. If a baud value was specified, hardware flow control
should be locked enabled. In many cases, software flow control provides
problems, and should locked disabled. The flow value can be any one or
more(providing they are not repeated) of the following: [-]H to lock
enabled [or disabled] hardware flow control, [-]S to lock enabled [or
disabled] sending of software slow control codes, or [-]R to lock
enabled [or disabled] acting on received software flow control codes.
With most high speed modems, flow should almost always be set to
"H-S-R". However, locking software flow control disabled may provide
problems with some FAX software.
Section 5-2-2: Setting Buffer Sizes
Increasing buffer sizes often makes applications more efficient and
increases the application's performance. While the default buffer
values work fine on most DOS only based systems, users of multitasking
environments may find they need larger buffers. ONEFOSsil provides a
single option that permits setting buffer sizes, along with flow control
threshold values. ONEFOSsil is the only communications driver known to
allow the user to tweak the flow control thresholds. The syntax for the
buffer configuration command follows:
B=[write][,[read][,[stop][,[continue]]]]
What this shows is that all values are optional. If a value is not
specified, a comma should still be placed for the missing value.
Trailing commas are not permitted, and of course, if no values are
specified, one should not place B= on the command line.
The write value specifies the size in bytes of the transmit buffer.
Valid values for write range 32 through 32767 and defaults to 1024. A
common rule for setting the buffer is to set the buffer large enough to
hold one second worth of data. An ideal value for write is 1024 to
5760.
The read value specifies the size, in bytes, of the receive buffer.
Valid values for read range 32 through 32767 and defaults to 1024. A
common rule for setting the buffer is to set the buffer large enough to
hold one second worth of data. An ideal value for read is 1024 to 5760.
The stop value specifies the point at which there is too little room in
the receive buffer and flow control should be engaged to prevent an
overrun of the receive buffer. Valid values for stop range 0 through 1
less than the read value and defaults to ¼ of the read value.
The continue values specifies the point at which there is enough room in
the receive buffer to safely disengaged flow control after it has been
engaged, allowing more data to be received. Valid values for continue
range 1 through the value of read and defaults to ½ of the read value.
The continue value must be larger than the stop value.
Notes
■ The total size of the buffers can not exceed the memory limit of the
driver. ONEFOSsil occupies about 4k of memory, so the remaining 60k
of the memory available to it may be split between the two buffers.
■ A receiver buffer size of 32 should only be used on very slow modems
or serial connections. Otherwise, the receive buffer size should
never be less than 64 bytes.
■ The stop and continue values are automatically calculated based on
the read value, and it is strongly suggested not to attempt to change
the default settings.
Section 5-2-3: Setting Multitasker Options
ONEFOSsil provides a means to detect when some applications are idle,
and return their time slice to the multitasker. For this to work, the
application must be using ONEFOSsil and you must be running in a
supported multitasking environment. Currently both DESQview and Windows
are supported. ONEFOSsil does not detect which multitasker it is
functioning on, so defaults to not returning time slices. The syntax
for setting the multitasker options follows:
S=os[,sensitivity]
The os value specifies which multitasker ONEFOSsil is to return time
slices to. Valid values are D for DESQview and W for Windows.
The sensitivity value is optional, and specifies the sensitivity
ONEFOSsil is to measure before returning time slices. Valid values for
sensitivity range 0 through 255 and defaults to 128 if not specified.
This value works somewhat like Windows 95's MS-DOS Program Properties
Idle Sensitivity slider. Smaller values yield more time slices; larger
values yield fewer time slices. There is no known ideal value. Some
applications have been found to be so efficient at making FOSSIL calls
that ONEFOSsil can not detect their idleness.
Section 5-2-4: Controlling FIFO's
ONEFOSsil is considered the be one of the few communications driver to
permit the user to configure the usage of the 16550 receive and transmit
FIFO's independently. This was done because when using the new
multitasking environment's virtualized communications ports, there is
performance to be gained. Please read Compatibility Notes - Windows
Tips for more information when running under Windows or Windows 95. The
FIFO settings option is only valid if the UART was detected with working
FIFO's. The syntax for controlling the FIFO's follows:
F=buffer[,trigger]
The buffer value specifies the number of characters ONEFOSsil will
buffer into the UART's transmit FIFO. Valid values for buffer are 0
through 255, and defaults to 16 on the 16550. The buffer value should
not exceed the number of transmit FIFO's the UART has. A 16650 may be
capable of buffering 32 characters, but has not been tested. A value of
0 forces FIFO's to be entirely disabled.
The trigger value is optional, and may only be specified if the buffer
value was specified. The trigger value is a code that specifies how
many characters must be received before the UART will request ONEFOSsil
to read them. Current values for trigger range 1 through 4 and defaults
to 3. On a 16550 UART, the trigger value causes the following results:
trigger characters received
------------------------------
1 1
2 4
3 8
4 14
Generally, trigger should be set at 3 unless problems occur. If
problems like CRC errors occur frequently when pressing a key or
switching tasks, the trigger value should be reduced. However, special
settings apply for Windows, documented in Compatibility Notes - Windows
Tips.
Section 5-2-5: Holding the Interrupt
Under some circumstances, it might be dangerous for ONEFOSsil to hook
and unhook the UART's interrupt request vector only when needed. The
hooking option forces ONEFOSsil to hook the interrupt at installation
time rather than when needed by an application. The syntax for the
hooking option follows:
H
The hooking option will not prevent applications from hooking on top of
ONEFOSsil, and does not prevent applications from stealing the UART's
hardware interrupt request or FOSSIL services vectors from ONEFOSsil.
It is primarily provided for users that load ONEFOSsil before the
multitasking environment, but may not be required. There are also
circumstances documented in Compatibility Notes - Pretested Software
that require the use of this option.
Section 5-2-6: Controlling Time-outs
Some functions in the FOSSIL specification will not return until they
have been satisfied. Hardware problems wreak havoc with this, and may
cause unexplainable lock-up's. ONEFOSsil provides a configurable
time-out option to force these functions to return after the preset time
period. This helps reduce the chances of sudden hardware problems from
completely locking up a system. The syntax for the time-out option
follows:
T=time
The time value specified the length of time that ONEFOSsil will wait for
a function to complete when failing. The unit of time is seconds, and
valid values range 0 through 3599 (60 minutes), and defaults to 30. If
other FOSSILs provide a time-out condition it is generally 30 seconds,
Some FOSSILs will never time-out. The BIOS communications routines
usually time-out after 2 seconds; however, most FOSSIL compatible
software are wrote to skip time-outs, and so too small a value will
cause lost characters during flow control. Time-out values are accurate
to 1,080/19,663rds of a second.
Section 5-2-7: Controlling Carrier Detection
ONEFOSsil provides a means of delaying carrier drops or providing
applications with a continuous carrier detection. This is known as
providing a fake carrier detect, and ONEFOSsil is known to be the only
FOSSIL driver that provides the user such an option. Providing a delay
for carrier drops may improve connections on 2400bps or slower modems.
Providing a fake carrier detect is a software means of solving a faulty
or incorrectly wired null-modem cable, or enabling software to work with
a 3-line cable. The syntax for the delayed carrier option follows:
D[=delay]
Specifying the D without a value forces the carrier detect to be always
active on this port. When an application requests the port status,
ONEFOSsil will always report that there is carrier present. If the
optional delay value is specified, ONEFOSsil will delay the carrier from
dropping for delay units of time. The unit of delay is 1,080/19,663rds
of a second, or approximately 1/18th of a second. Valid values for
delay range 1 through 32767 (30 minutes). A common value, if needed, is
18, which provides about 1 second for the carrier to recover. This is
used primarily on old 1200 or 2400bps modems which permit the carrier
detect line to drop during line noise. Newer models of slower modems no
longer need this as they perform like high speed modems, which only drop
the carrier detect line when the connection has been terminated.
This option is provided to make ONEFOSsil possibly the most complete
communications driver. This option may be often useful for people
trying to figure out how to tie two computers together and can't get
their software to work without a carrier detect. For those who can wire
a cable, the following will help: On each end of the cable, short the
lines named DSR and DCD together. This provides a carrier detect based
on the DTR. Then to lower the DCD to fake having "hung up" one would
lower the DTR line. Most communications programs lower DTR to hang up
modems, so this works well on computer to computer connections.
Section 6: After Installation
After ONEFOSsil has been installed, ONEFOSsil can manipulate some of its
functions or change its parameters. The syntax for using ONEFOSsil to
execute its commands follows.
ONEFOS port [command]
The port argument works the same as if ONEFOSsil was installing itself.
Generally port 1 refers to COM1. The following commands apply to the
command value.
A more complete utility is coming soon from the author that will enable
its users to do almost anything to the FOSSIL driver from a batch file.
More on this when the time comes.
Section 6-1: Un-installing
After having been installed, ONEFOSsil can be removed from memory when
its services are no longer needed. The following is the syntax for the
un-install command.
U
ONEFOSsil will attempt to remove itself from memory. If it is unsafe to
do so, an error will be display, and ONEFOSsil will remain in memory.
Different versions of ONEFOSsil will not un-install each other. An
error level of 0 is returned if ONEFOSsil successfully removed itself.
Section 6-2: Getting Status
Getting the status of a ONEFOSsil port is not currently available. It
simply hasn't been completed. When it is completed, it will provide
some information about the current conditions of the specified ONEFOSsil
port. It will also be able to display some information about other
FOSSIL driver's ports.
Section 6-3: Changing Port Settings
Changing the port settings of a ONEFOSsil port is not currently
available. It simply hasn't been completed. When completed it will
permit both changing the locked parameters or just the current settings
for port speed, data format, and flow control.
Section 6-4: Forcing Port Opened
ONEFOSsil can be used to force a port activated. This is not specific
to ONEFOSsil ports, and may be used with any FOSSIL driver. The syntax
for opening a port follows.
O
ONEFOSsil will attempt to open the specified port, and will report its
success or failure. ONEFOSsil will exit with an error level of 0 if it
was successful.
Section 6-5: Forcing Port Closed
ONEFOSsil can be used to force a port deactivated. This is not specific
to ONEFOSsil ports, and may be used with any FOSSIL driver. The syntax
for closing a port follows:
C
ONEFOSsil will attempt to close the specified port, and will report its
success or failure. ONEFOSsil can not insure that it was successful
though, but will exit with an error level of 0 if it appears to have
worked.
Section 7: Examples of Installation and Use
This section will show some examples on how ONEFOSsil is installed and
used. These examples usually will not be sufficient by themselves, but
they provide hints on how options are used in case the descriptions
above were not clear enough.
Installing ONEFOSsil on standard COM1 which is running a 28800bps modem.
This will set the buffers to allow for one second of data.
ONEFOS 1=03F8,4 L=115200,8N1,H-S-R B=4096,4096
Installing ONEFOSsil on a completely non-standard port, locking the baud
rate at 38400, data format at 8N1, and hooking the hardware interrupt at
load time.
ONEFOS 5=3480,13 L=38400,8N1,H H
Installing ONEFOSsil on COM4 using IRQ 7 locking the data format at 7
data bits, even parity, 2 stop bits, and locking software flow control,
with very small buffers.
ONEFOS 3=02E8,7 L=,7E2,SR B=64,64
Un-installing ONEFOSsil from COM3.
ONEFOS 3 U
Opening COM1 after ONEFOSsil has already been installed.
ONEFOS 1 O
Section 8: Compatibility Notes
These sections include some tips and other issues on using ONEFOSsil in
specific environments or with specific software. Some of these tips may
have been reported by users, but have usually been tested. Some
suggestions may not always work under some circumstances. You use these
suggestions at your own risk.
Section 8-1: Shared IRQ's
ONEFOSsil supports ports that share the same IRQ. Under DOS or
DESQview, this will only work if ONEFOSsil is the last driver to use the
interrupt and is loaded before the multitasker. Any number of copies of
ONEFOSsil should be able to share the same IRQ. Under Windows or
Windows 95, it is believed that ONEFOSsil will work even if loaded in
each window. This is due to how Windows virtualizes the communications.
Please read Windows Tips for more information.
Section 8-2: Pretested Software
The following software notes have been taken during testing and normal
use of ONEFOSsil.
DOORWAY: If you use DoorWay 2.3 or earlier, possibly later versions too,
you MUST use the H option when installing ONEFOSsil, or the O command
before running DoorWay. DoorWay has a bug dealing with the order in
which it saves and restores the interrupt table and initializes and
deinitializes the FOSSIL driver.
CEXYZ: If you use CEXYZ as a protocol driver, under a multitasker,
performance may drag, specially on receiving. Everything is ok if run
in DOS. It appears to be CEXYZ's multitasking support. ZSXW works fine
and gets much better performance under Windows and DESQview.
DDPLUS: Any door written with DDPlus version 7.1 or earlier, possibly
later versions too, will not work with ONEFOSsil if set to use XFOSSIL
(otherwise known as the X00 Extended FOSSIL mode). DDPlus driven doors
will not even work with X00 in that mode. Instead all calls to the
FOSSIL end up in the BIOS COMM routines. This is probably in how DDPlus
is detecting an X00 FOSSIL, which just plain won't work with ONEFOSsil.
Doors affected by this include LORE 2.00, LORD 3.52 (except it is not
apparent), USURPER 1.13b and many others.
Software tested: Renegade BBS, FHSLink, L.O.R.D., Planets: TEOS,
Usurper, Galactic Overlords, Global War, DoorWay, CEXYZ, RIPVersi, LORE,
FOSSILC (unreleased version), B.R.E., Portal of Power, FrontDoor,
Intermail, ZSXW, RIPSweeper, WildCat!, and a few others.
Section 8-3: Windows Tips
During development and testing, some tips for using ONEFOSsil under
Windows 3.11 and Windows 95 have been collected. Many thanks to those
in FidoNet's WIN95 echo for suggesting these tips. These tips have not
been tested under Windows 3.11, as it does not have all these options.
These suggestions will reduce, if not entirely eliminate, CRC errors and
increase performance. Also, these tips are not just for ONEFOSsil, but
apply to almost all communications under Windows 95.
It was found during testing of ONEFOSsil that Windows 95's
communications drivers have some bugs in how a 16450 UART is
initialized. As such, if the first port accessed by a DOS application
after Windows has been loaded is a 16450 UART port, it is likely that
the application that uses the port will drop lots of characters,
specially at higher speeds. This is not specific to ONEFOSsil as all
DOS communications software were found to have the same problem.
Generally, there are no problems if a 16550 UART port is accessed before
a 16450 UART port is accessed. The problem also seems to disappear once
the DOS window has been closed and re-opened.
One may find communications in Windows 95 to be very temperamental if an
IRQ above 8 is used for a COM port IRQ. The conditions would come and
go from reboot to reboot. Generally the UART's interrupt would be
disabled whenever a character was received, and could cause system
locks. This was generally made even worse when combined with the above
problem. The only solution is to try to keep COM ports using IRQ's
lower than 8.
The following tip was partially suggested by Bill Gaston on FidoNet's
WIN95 echo. Most of the suggestion he posted as been complemented with
the authors complete testing of the suggestion. As such, there have
come to be some differences even between Bill's and the author's
original publication of this tip. Perform the following steps to
improve DOS programs performance and reliability while running in
Windows or Windows 95.
Open the Control Panel.
Open the System Properties icon.
Select the Device Manager tab.
Expand the Ports branch.
Carry out the following steps on each COM port.
Press the Properties button.
The properties on this page are only used as defaults for Windows
programs; however, make sure everything is correct, such as
the Flow Control setting should usually be set to Hardware.
Press the Advanced... button.
Press the Defaults button to set the FIFO values at 3 notches and
4 notches respectively. This works the best for most all
systems, and appears to be used even for DOS applications.
Press the OK button to return to the Properties tab.
Press the OK button to return to the Device Manager.
Close the System Properties window to save the changes.
Open the file \Windows\System.ini with an editor.
Make the following changes to the [386Enh] section.
Remove or remark any "COMBoostTime=" statements. It was
earlier suggested to add this statement, but the
author has found applications perform better without
it.
Add or change the statement "MinTimeSlice=" to read
"MinTimeSlice=30". This greatly improves the
performance of LORE and BRE while the are in the
background.
Add or change the statements "COMxBuffer=y" for each COM
port used by DOS applications. The value y is the
amount of buffer space to be reserved for COMx.
Ideally, a value larger than ONEFOSsil's read value
should be used. This will greatly improve performance
and reliability of DOS applications.
On the ONEFOSsil command line, the FIFO settings can be set to F=16,4 to
provide better results on 16550 UARTS. This sets the FIFO's to maximum
for both transmit and receive FIFO's.
It is also suggested to run the UART at as high of a speed as can be
supported by the modem. This increases performance specially with error
correcting and data compression modem protocols.
Just to note, these settings have completely eliminated CRC errors on
the authors 4 megabyte system on all 16550 UART ports. Ports using
16450 UARTs do not produce CRC errors even running at 38400bps (direct
link between computers).
Section 9: Troubleshooting
If you can not find an answer here, you are very welcome to read the
SUPPORT.TXT file and use any valid means for contacting the author to
discuss the problem.
This section will be maintained in FAQ (Frequently Answered Questions)
format.
Q: I get CRC errors in Windows or Windows 95, can this be solved?
A: Usually. Please read Compatibility Notes - Windows Tips, above, for
more information. If problems persist, please contact the author
through the appropriate support channel.
Q: I have just a couple programs that refuse to work with ONEFOSsil,
everything else appears to work fine, what can I do?
A: Contact all authors involved. The author of ONEFOSsil may be able to
solve the problem, or provide a work-around, but the best long term
solution is to correct the bugs other programs may have. It reduces the
chances that other problems will be created in the future.
Q: ONEFOSsil refuses to install, stating that the UART doesn't exist,
why is this?
A: ONEFOSsil does a test that almost always insures the UART and the
interrupt hardware are functioning before loading. Under multitaskers,
if another window or task already has the port to itself, ONEFOSsil may
not be able to recognize the UART (as in the case with Windows) or may
find the interrupt hardware to be failing (as in the case with
DESQview). Try closing all windows or loading ONEFOS in DOS. If it
still refuses to work check all settings. After running out of
possibilities, attempt to contact the author to see if you don't have
unsupported UART hardware. ONEFOS has been tested to work on internal
modems, 16550's, 16450's, and on 12mhz 80286 processors. Even faster
machines may provide problems with how ONEFOSsil detects UART's, however
no problems have been reported yet.
Q: I tried to get ONEFOSsil to report its status, or change its
settings after it has been installed, but I keep getting a command line
error message, why?
A: RTFM! Those commands are documented above as being unfinished. It
is the hope of the author to have all ONEFOSsil commands completed at
revision 10. At that time the whole project will be given a better
command line processor, and better help when an error occurs.
Q: Any other questions, anyone?
Section 10: Credits
All trademarks and copyrights mentioned in this documentation are the
property of their owners. References to companies or their products are
in no way an advertisement or a guarantee that this product will work
with the mentioned products or environments.
Thanks the most to Ralph Brown and others for the Interrupt List
(version 48). Without the Interrupt List and its many other components,
this project would have flopped from all the misleading sources I used.
Yes, the Interrupt List is not perfect, but not nearly as bad as some of
the other sources I used in this project.
Thanks also to Allen L. Wyatt, Sr. for "Advanced Assembly Language"
(ISBN 1-56529-037-2) which provided me with just enough (misleading)
information to start on the project. Many sample programs contradict
information shown in the charts, but they all seem to run, and I do plan
to use more of the book than the "Serial Communications" chapter.
Thanks also to Ray Gwinn for providing the specifications to his
slightly advanced FOSSIL specification. Yes, small errors here and
there too, but nothing the Interrupt List didn't clear up. It is also
his buggy DOS based FOSSIL driver, X00, and his supposed denounce of
Windows, that prompted for the creation of this driver. Bob Juge also
had some help in getting me to write this driver, with his persistent,
"the X00 specs are publicly available."
Thanks a little to Barb Maly, for constantly reminding me why she didn't
use X00, and why I didn't use BNU. She is also a primary beta tester
and is the primary distributor.
Dan Liston gets a little thanks too, for allowing me to test my driver
on repeated calls to his system. I know it had to be annoying.
Many thanks to everyone in the FidoNet WIN95 support echo. Their
support has helped to make ONEFOSsil more complete.
<EoF>